This invention relates to methods of improving security in transacting electronic commerce. More specifically, the invention defines a framework which enables trusted brokers running in an insecure network such as the Internet to offer more secure payment facilities.
Electronic commerce is based on the electronic exchange of items, one of the typical exchanges is an electronic payment but it may also be a digitally signed contract. An important requirement for security in the exchange of items is fairness. An exchange is fair if, at the end of the transaction, either party receives the item he expected, neither party receives it, or each party obtains a legally binding receipt of the transaction which can be submitted to a third party for resolution, in the event that the received item does not meet expectations. At present, such commerce is typically conducted directly between a user and a merchant (of course, with the intervention of a bank in obtaining payment), representing a direct point-to-point contact on the Internet. In the context of electronic commerce, transactions or exchanges may be carried out over insecure networks. Unfortunately, it is possible for a hacker to exploit vulnerabilities in protocols and applications or to corrupt systems used by the other party. Therefore, carefully designed exchange protocols are used to help guarantee security in electronic commerce transactions. The Secure Socket Layer or “SSL” secure communication protocol, introduced by Netscape in 1994, is an example of such a protocol. This protocol provides encryption and authentication between web browsers and servers, such as between users and merchants, and is characterized by requiring very little processing power to utilize. SSL is commonly used for sending encrypted credit card numbers over the Internet. A substantially more secure payment protocol, requiring significantly greater computing power, was introduced by Mastercard, VISA, and others in February, 1996 (upgraded in June, 1996). This protocol is known as the Secure Electronic Transaction or “SET” protocol. Its purpose is to provide confidentiality of information, ensure payment integrity, and authenticate both merchants and cardholders. The current computing requirements for implementing the SET protocol make it inappropriate as a protocol for shopper/users to run directly from their browser. If such were used by the user, for example, in downloading an applet, downloading times and performance losses would likely increase to unacceptable levels.
Further, unless the user has some mechanism of fair exchange, the user must trust the merchant, an entity with whom the user may not have had dealings and about which he is only able to obtain information from the merchant himself. The justifiable lack of trust in a merchant-server's self certification (e.g., the fear of merchant fraud) tends to limit the growth and acceptability of electronic commerce. Therefore, even when organizations use the SET protocol to perform payment functions, the user's lack of anonymity is a disadvantage.
The prior art describes various attempts at improving security. These attempted solutions fall into two categories: (1) third party protocols which make use of a trusted, on-line third party who is typically registered as such by a neutral entity, and (2) gradual exchange protocols in which the probability of obtaining a fair exchange is gradually increased over several rounds of communications. In common commercial terms, this latter protocol is comparable to a “course of dealing” between the parties involved in the exchange. In the trusted third party approach, organizations managing a trusted third party must conform to a number of requirements. For example, a trusted third party may be required to (1) meet minimum financial criteria, (2) to possess insurance against fraud, and (3) be socially credible. Proper adherence to and implementation of these requirements ensures that information disclosed by users to a trusted third party is handled in a secure manner.
In U.S. Pat. No. 5,592,375 a system for brokering goods or services between buyers and sellers is described whereby the buyer is provided an aid in selecting among the variety of products. The buyer and the seller are connected to computers via a brokering system including a database, a customers interface and a buyers interface. The buyers interface provides a knowledge based interactive protocol enabling the buyer to select and review the respective information from the database. The session between the buyer and his client is rendered secure by using the identification of the buyer and some security information. The system can be particularly used for assisting an employer in hiring. EP A 0854 462 discloses a system with a broker server which is arranged in between a customer and a merchant and a method of trading in two steps including sending electronic money from the consumer to broker's server and from the brokers, to the merchant. Cryptography maybe used to transmit and receive data for achieving confidence and authentication.
The prior art solutions have shortcomings. For example, the third party method runs the risk of the third party becoming a bottleneck due to the fact that a single trusted third party may be asked to serve as such in a number of widely varying transactions.
Alternate fair-exchange protocols involve the use of third party servers in exceptional circumstances, such as in the case of disputes. For example, both parties agree on the items to be exchanged and which third party to use in case of an exception. This is known as the optimistic approach to using a third party. Only the risk-taking party (the originator) may invoke the third party (due to the customer being unsatisfied with the bought merchandise). The merchant may also complain as well (e.g., regarding an invalid check). Thus, this method helps overcome the traditional risk of the trusted third party becoming a bottle neck, but limits the recourse of the other party. Other approaches have used an overall time limit parameter which ensures that, should the risk-taking party not invoke the third party, the other party will be able to resolve the transaction.
Other methods have been developed with varying degrees of effectiveness. Most either lack sufficient effectiveness, do not provide anonymity, or require substantial processing time or processing power on the part of the parties involved.
Therefore, what is needed is a method of improving the security of an electronic exchange (with both fair exchange and anonymity of the user) which does not require excessive processor time or increase the hardware requirements of the user.